%-----------------------------------------------------------------------------
\chapter{Conclusion}
%-----------------------------------------------------------------------------



%Noch nachsehen Überschriften Punkte
%Vorhergehende Bachelorarbeit(en)




\section{Development}
Developing with the Spring framework especially utilizing Spring
data repositories and Hibernate as object relational mapping software is very
intuitive. The frameworks are very powerful, take a lot of work out of
developers hands by providing clear interfaces and do much automatically in the
background. Although they are well documented, many working examples are
provided - either through the manufacturers themselves or via third parties -
and individual modules are quit easy to understand the effort to get to know and
to learn to work with all required modules must not be underestimated.
Especially wiring all individual modules together to a working solution is very
time intensive and a big learning effort. This especially plays a big role when
standard solution paths provided by the frameworks are left as is the case in
the described solution.



\section{Unresolved problems}
%Nochmals nachsehen
%Vorhergehende Kapitel
The provided solution implies tight coupling between the old customer class
``Customer'' and the new customer class ``CustomerRefactored'' because they have
to store references to each other, as shown. This is generally undesired in
software systems because it impedes future changes. Furthermore the provided
solution in a kind of abuses Hibernates object relational mapping because the class
``Customer'' still has to contain specific annotations - ``@Entity'', ``@Id'' -
in order to work properly, although it does not do any database interaction
anymore. Furthermore additional code has to be developed to tie original and
refactored software classes together. Beside the fact that Spring data
repository methods that otherwise would be provided by the framework itself have
to be implemented additionally manually.




%\section{Possible optimizations}
%Service layer lassen
%Später noch möglich
%Wenn dann Conclusion
%Ausbessern und verweisen


\section{Conclusions and suggestions}
A technique how database structures can be refactored without changing existing
program code on the domain layer - or above - of typical Java Spring
applications - that do not need change from a business view of perspective - has
been shown and demonstrated. Additionally it has been shown that the refactoring
can be done safely utilizing unit tests for domain layer software modules.
This because they have not been altered for the refactored application but still
can be executed without raising errors. Furthermore the HTML front end as the
REST data interchange interface can be used as before refactoring. However,
because of its unresolved problems this approach can only be suggested if
modifying domain layer software modules has to be circumvented in any or at
least almost any case.


